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I.  INTRODUCTION 


In  October  2002,  the  Research,  Development  and  Engineering  Command  (RDECOM)  was 
established  by  the  Army  Materiel  Command  (AMC)  to  integrate  the  research,  development  and 
engineering  components  of  AMC  subordinate  commands.  A  Virtual  Distributed  Laboratory  for 
Modeling  and  Simulation  (VDLMS)  was  initiated  and  selected  to  execute  the  RDECOM ’s  First 
Application  (L*App). 

The  objectives  of  C*App  were  to  provide  insights  into  the  Networked  Fires  process  and 
performance  for  Future  Combat  Systems  (FCS),  and  to  define  the  baseline  capability  of  the 
VDLMS  as  it  transitions  towards  the  Modeling  Architecture  for  Technology,  Research,  and 
Experimentation  (MATREX). 

L*App  was  designed  as  a  distributed  real-time  simulation  architecture  utilizing  established 
and  emerging  models  and  simulations  at  key  RDECOM  Modeling  and  Simulation  (M&S) 
facilities,  linked  with  representative  test  and  user  communities.  Key  analysis  agencies  also 
participated  in  experimental  design  and  execution,  but  did  not  provide  real-time  M&S  elements. 

Geographic  distribution  of  the  event  was  accomplished  by  linking  four  simulation  sites  with 
one  wide  area  network  monitoring  and  collaboration  server  site,  and  physically  bringing 
resources  from  the  other  VDLMS  organizations  to  the  four  simulation  sites,  (Fig.  1)  where  green 
circles  indicate  distributed  sites,  tan  circles  indicate  organizations  not  at  own  sites,  and  blue 
circles  indicate  personnel  support  only.  Roles  for  these  organizations  are  identified  as  follows: 
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Figure  1.  F‘App  Distributed  Network 

1 .  Wide  area  network  monitoring  and  eollaboration  server  site: 

•  Defense  Researeh  and  Engineering  Network  (DREN),  Army  Research  Laboratory 
(ARL), 

Aberdeen  Proving  Ground,  MD 
o  Wide  Area  Network  Support 

2.  Distributed  Simulation  Sites: 

•  Aviation  and  Missile  Research,  Development,  and  Engineering  Center  (RDEC) 
(AMRDEC),  Redstone  Arsenal,  AL. 

o  Aviation,  Missile,  and  Unmanned  Aerial  Vehicle  (UAV)  Simulations 
o  Networked  Fires  Technical  Lead 
o  Data  Collection  and  Analysis  Lead 
o  Battlemaster 

•  RDECOM  Simulation  Technology  Center  (STC),  Orlando,  FL 
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o  OneSAF  Test  Bed  (0TB) 
o  Data  Collection  and  Analysis  Support 

•  Communications  and  Electronics  RDEC,  (CERDEC),  Ft.  Belvoir,  VA 

o  Reconnaissance,  Surveillance,  and  Target  Acquisition  (RSTA)  Suite 
o  Unmanned  Sensor  Models 

•  Redstone  Technical  Test  Center  (RTTC),  Redstone  Arsenal,  AL 
o  Test  Data  Collection 

3.  Remote  Site  Organizations: 

•  Armaments  RDEC  (ARDEC)  -  (at  AMRDEC) 

o  Armaments  and  Munitions  Models 
o  Weapon/Target  Pairing 

•  ARE  -  (at  STC) 

o  Vulnerability/Lethality 

•  Tank  and  Automotive  RDEC  (T ARDEC)  -  (at  RTTC) 

o  Armed  Reconnaissance  Vehicle  (ARV)  Models 
o  Vehicle  and  Mobility  Models 

•  CERDEC  Monmouth  -  (at  AMRDEC  and  CERDEC  Ft  Belvoir) 

o  Command,  Control,  Communications  (C3) 
o  Sensor  Fusion 

•  Depth  and  Simultaneous  Attack  Battle  Lab  (D&SA  BE)  -  (at  AMRDEC) 

o  Networked  Fires  Operational  Lead 
o  Networked  Fires  Models 
o  Blue  Force  Roleplayers 
o  Scenario  Development  and  Approval 

4.  Coordinating  Organizations: 

•  Army  Materiel  Systems  Analysis  Activity  (AMSAA) 

o  UA  Systems  Book 
o  VV&A  and  Networked  Fires  Analysis 

•  TRADOC  Analysis  Command  (TRAC)  Ft  Leavenworth  (FLVN) 
o  Networked  Fires  Process 

•  Threat  Systems  Management  Office  (TSMO) 
o  Threat  Roleplayers. 

•  Unit  of  Action  Maneuver  Battle  Lab  (UAMBL) 
o  Scenario  Development  and  Approval 
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II.  ARCHITECTURE 


C‘App  architectural  design  was  based  upon  the  requirement  to  utilize  existing  RDECOM 
facilities  and  simulations,  which  necessitated  the  physical  backbone  and  simulation 
infrastructure  to  derive  from  those  currently  in  use  to  support  RDECOM  customer  experiments. 
A  High  Level  Architecture  (HLA)  simulation  backbone  was  laid  across  the  physical  connectivity 
to  provide  simulation  interactions.  Sub-networks  of  Distributed  Interactive  Simulation  (DIS) 
traffic  were  bridged  into  the  HLA  architecture  at  three  sites,  then  the  appropriate  HLA  federates 
and  DIS  simulations  were  connected  to  provide  the  overall  digital  architecture. 

In  addition  to  the  digital  simulation  network,  C'App  also  utilized  digital  collaborative 
environment  tools  and  analog  commercial  voice  conference  calls  to  support  experiment  control 
and  tactical  voice  communications.  The  entire  architecture  design  is  shown  in  Figure  2. 
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Figure  2.  App  Federation  Diagram 
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A.  Wide  Area  Network  (WAN)  Architecture 

The  distributed  simulation  sites  mentioned  previously  are  all  connected  to  the  DREN, 
and  have  historically  utilized  the  DREN  to  connect  their  real-time  simulation  capabilities, 
particularly  in  support  of  the  RDEC  Federation  Calibration  Experiment  (CalEx)  [1,2], 

A  driving  requirement  for  the  physical  architecture  was  classified  operation.  While 
encryption  devices  added  complexity,  they  improved  connectivity  experienced  during  CalEx  by 
allowing  the  network  to  bypass  metropolitan  area  network  firewalls  and  access  control  lists.  A 
detailed  discussion  of  the  l®*App  network  design  and  performance  is  given  in  Reference  3. 

B.  Simulation  Architecture 

Most  of  the  existing  RDECOM  simulations  were  developed  using  DIS  protocols  for 
interconnectivity,  and  have  demonstrated  compliance  with  HLA  using  the  Real-time  Platform 
Reference  (RPR)  Federation  Object  Model  (FOM)  and  DIS/HLA  gateways. 

During  CalEx,  the  RDEC  Federation  experimented  with  RPR  FOM  extensions  to  pass 
non-DIS  compliant  information,  such  as  target  acquisition  truth  data,  and  distributed  data 
collection  information.  However,  during  the  design  of  C‘App,  it  proved  possible  to  configure  all 
data  exchanges  into  DIS  compliant  Protocol  Data  Units  (PDUs)  and  corresponding  RPR  FOM 
data  without  the  need  for  extensions.  This  allowed  use  of  commercial  DIS/HLA  gateways 
without  customization. 

In  addition  to  the  gateway  federates,  there  were  several  native  HLA  federates,  also 
indicated  in  Figure  2.  In  order  to  control  and  limit  WAN  traffic  and  avoid  feedback  loops,  only 
HLA  traffic  was  allowed  to  pass  across  the  WAN.  Consequently,  any  DIS-to-DIS  traffic  between 
sites  had  to  pass  through  two  gateways  to  encode  and  decode  data  packets,  which  impacted 
performance  in  terms  of  data  latency.  This  led  to  the  addition  of  a  small  red  cell  at  the  CERDEC 
site  to  allow  for  local  blue/red  force  interactions. 

C.  Experiment  Control  and  Data  Collection  Tools 

U'App  utilized  the  Mak  HLA  Run-Time  Infrastructure  (RTI)  and  Mak  gateways  as 
commercial  products.  The  RTI  Execution  (RTI  Exec)  process  was  run  from  the  experimentation 
control  and  data  collection  cell  at  AMRDEC. 

The  commercial  product  “HLA  Results”  was  used  as  the  primary  distributed  data 
collection  tool.  HLA  Results  was  run  on  several  platforms  to  allow  simultaneous  data  collection 
during  runs,  post-processing,  and  analysis  queries. 

U'App  also  utilized  the  AMRDEC-developed  Data  Collection  and  Analysis  Tool 
(DC  AT)  for  real-time  monitoring  of  battlefield  statistics.  DC  AT  was  originally  developed  for 
DIS,  and  was  converted  to  an  HLA  interface  in  support  of  CalEx.  Since  the  underlying  data 
structures  for  DCAT  are  still  DIS  PDU  based,  it  was  closely  aligned  to  RPR  to  support  U‘App. 
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While  DCAT  focused  on  effects  data,  another  run-time  data  collection  tool  was 
developed  from  a  G2  rules-based  engine,  which  provided  real-time  monitoring  of  target 
acquisition  and  fires  process  data,  user  selectable  during  the  runs. 

0TB  and  the  Vulnerability/Lethality  server  were  also  used  in  data  collection  modes, 
even  though  those  simulations  are  typically  used  as  simulation  truth  data  generators.  Since  0TB 
was  not  the  primary  scenario  generator  simulation  for  l**App,  it  was  used  to  monitor  battlefield 
entity  status  and  enumerations  to  reduce  risk  for  later  use  of  0TB  in  MATREX  events.  Likewise, 
the  Vulnerability/Lethality  server  will  eventually  be  responsible  for  setting  the  damage  states  for 
MATREX  entities,  but  for  1^‘App,  it  was  used  to  monitor  state  changes  for  verification  purposes. 

Other  typical  data  collection  and  viewing  tools  such  as  plan  view  displays  and  stealth 
viewers  were  also  used  as  needed. 

D.  Truth  Data  Simulations 

E'App  was  scoped  to  represent  the  quantities  and  types  of  systems  composing  an  PCS 
UA,  based  on  the  UA  Systems  Book,  using  the  then-current  version  1.6  document. 

The  primary  scenario  engine  for  l**App,  providing  platform-level  performance  for  the 
bulk  of  the  red  and  blue  forces,  was  the  AMRDEC-developed  Interactive  Distributed 
Engineering  Evaluation  and  Analysis  Simulation  (IDEEAS).  IDEEAS  is  a  constructive 
simulation  which  is  synchronized  with  real-time  to  support  virtual  experimentation,  with  a  low 
level  of  runtime  user  interactions.  All  entities  in  l®*App  were  generated  by  IDEEAS,  except  as 
identified  with  the  other  models  described. 

FIRESIM  from  D&SA  BE  was  used  to  represent  all  red  and  blue  indirect  fire 
platforms,  with  the  exception  of  about  half  of  the  Non  Line-of-Sight  Launch  System  (NLOS  LS) 
platforms  which  are  otherwise  represented  by  the  NLOS  LS  Mission  Management  Applications 
(MMAs).  FIRESIM  was  also  utilized  to  represent  all  counter-battery  radar  systems. 

0TB  represented  a  small  number  of  air  sensor  platforms  used  to  populate  fused  sensor 
data.  0TB  also  represented  the  local  red  ground  force  at  CERDEC  for  interaction  with  RSTA 
simulations. 

When  launch  platforms  fired  missiles  and  armaments,  the  flights,  interactions,  and 
detonations  of  those  entities  were  generated  by  the  Missile  Server  from  AMRDEC  and  the 
Armament  Servers  from  ARDEC. 

The  TARDEC  manned  simulator  and  Human  Performance  Model  (HPM)  represented 
two  RSTA  vehicles,  which  controlled  ARV’s.  The  CERDEC  manned  simulator  suite  represented 
a  single  RSTA  vehicle,  which  also  controlled  a  Class  I UAV,  a  Small  Unmanned  Ground 
Vehicle  (SUGV),  an  Unattended  Ground  Sensor  (UGS)  suite,  and  an  Intelligent  Munition 
System  (IMS).  There  were  also  several  desktop  simulators  of  Class  I-IV  UAV’s,  and 
dismounted  forward  observers  at  AMRDEC. 
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E.  Perceived  Data  Simulations 


C3  functionality  was  focused  on  those  functions  critical  to  Networked  Fires,  which 
included  target  reporting,  sensor  fusion,  situational  awareness,  weapon-target  pairing,  calls  for 
fire,  fire  missions,  and  Battle  Damage  Assessment  (BDA). 

Communications  representations  were  limited  to  two  key  areas:  communications 
between  ground  sensor  suites  and  the  RSTA  vehicle,  which  were  simulated  by  the  CERDEC 
ALCES  model,  and  communications  between  NLOS  LS  missiles  and  their  control  stations  and 
relays,  which  were  simulated  by  the  AMRDEC  Comms  Server. 

Many  of  the  existing  tools  from  the  RDECOM  organizations  had  overlapping 
functionality  in  Command  and  Control  (C2),  so  the  challenge  was  to  scope  meaningful  roles  for 
these  simulations  so  that  fire  missions  could  be  executed  at  various  levels  of  command. 
Collectively,  these  products  provided  the  functionality  of  a  Network-Centric  system  without 
explicitly  modeling  the  individual  nodes  and  interfaces  of  that  system. 

Mission  threads  were  represented  as  follows: 

Sensor  reports  from  various  RSTA  assets  were  sent  to  the  CERDEC  Sensor 
Exploitation  and  Management  System  (SEAMS)  simulation  for  fusion  and  forwarding  to  assets 
including  the  Mobile  Command  and  Control  (MC2)  system  and  Protocommand.  Other  sensings 
were  sent  directly  into  the  network  systems  without  the  fusion  function  occurring. 

MC2  then  updated  situational  awareness,  and  Protocommand  utilized  an  automated 
Attack  Guidance  Matrix  (AGM)  and  the  dynamic  organizational  allocation  of  fires  to  determine 
weapon-target  pairings.  MC2  also  sent  target  information  to  FIRESIM  for  processing. 

From  Protocommand  and  FIRESIM,  fire  requests  were  issued,  either  directly  to  firing 
platforms  or  for  further  allocation  to  the  ARDEC  Combat  Decision  Aiding  System  (CD AS), 
depending  on  which  echelon  of  command  was  executing  the  fires. 

For  fires  allocated  to  the  NLOS  LS  system,  depending  on  which  batteries  were 
assigned,  FIRESIM  or  the  NLOS  LS  MMA’s  determined  the  weapon  flight  paths  and  executed 
the  fires. 
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III.  METRICS 


The  two  1^‘App  objectives,  stated  as  issues,  were  as  follows: 

1.  Issue  1.0:  Defining  the  performance  of  the  legacy  M&S  architecture  as  a  baseline  for 
VDLMS. 

2.  Issue  2.0:  Matching  tactics  to  physics  to  produce  a  realistic  expectation  of  Networked 
Fires  performance  in  FCS. 

Two  sets  of  metrics  were  developed,  corresponding  to  these  two  l®*App  objectives.  These 
metrics  were  defined  in  a  dendritic  structure,  beginning  with  the  objectives  as  top-level  issues, 
decomposing  the  issues  into  sub-issues,  sub-issues  into  Essential  Elements  of  Analysis  (EEAs), 
EEAs  into  Measures  of  Effectiveness  (MoEs),  and  MoEs  into  Data  Requirements.  These  data 
requirements  were  used  to  drive  the  data  collection,  reduction,  and  analysis  requirements  for  the 
event. 

Following  are  the  sub-issues  and  EEAs  for  both  objectives: 

1 .  Sub-issue  1.1:  Defining  the  cost  of  execution  of  the  legacy  M&S  architecture  as  a 
baseline  for  VDLMS. 

EEA  1.1.1:  Actual  cost  of  execution  of  the  1  stApp  architecture  as  configured  to 
represent  FCS  Networked  Fires. 

2.  Sub-issue  1.2:  Defining  the  schedule  of  execution  of  the  legacy  M&S  architecture  as  a 
baseline  for  VDLMS. 

EEA  1.2.1:  Actual  schedule  of  execution  of  the  IstApp  architecture  as 
configured 

represent  FCS  Networked  Fires. 

3.  Sub-issue  1.3:  Defining  the  technical  performance  of  the  legacy  M&S  architecture  as 
a 

baseline  for  VDLMS. 

EEA  1.3.1:  Actual  performance  of  the  IstApp  architecture  as  configured  to 
representFCS  Networked  Fires. 

4.  Sub-issue  2. 1 :  Matching  tactics  to  physics  for  the  Sensor  component  to  produce  a 
realistic  expectation  of  Networked  Fires  performance  in  FCS. 

EEA  2.1.1:  Roles  of  sensors  to  support  targeting 

EEA  2. 1 .2:  Mix  and  quantities  of  sensors  to  provide  sufficient  and  dynamic 

threat  coverage  for  fires 

EEA  2.1.3:  Roles  of  sensors  to  support  BDA. 

5.  Sub-issue  2.2:  Matching  tactics  to  physics  for  the  Battle  Command  Component  to 
produce  a  realistic  expectation  of  Networked  Fires  performance  in  FCS. 

EEA  2.2.1:  Control  measures  needed  to  execute  fires 
EEA  2.2.2:  Role  the  CROP  plays  in  fires  processes. 
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EEA  2.2.3:  Ability  to  perform  dynamic  sensor  management 

EEA  2.2.4:  Comms  performance/limits  for  selected  arcs 

EEA  2.2.5:  Effectiveness  of  decision  aids  and  pre-planned  fires 

EEA  2.2.6:  Ability  to  perform  dynamic  redirection  and  massing  of  fires 

EEA  2.2.7:  Sensor/shooter  timelines  and  latencies 

EEA  2.2.8:  Degree  of  automation  of  fires  execution. 

6.  Sub-issue  2.3:  Matching  tactics  to  physics  for  the  Effects  Component  to  produce  a 

realistic  expectation  of  Networked  Fires  performance  in  FCS. 

EEA  2.3.1:  Ability  of  precision  munitions  to  acquire  targets 

EEA  2.3.2:  Ability  of  munitions  to  hit  targets  and  produce  damage 

EEA  2.3.3:  Fire  mission  service  and  success  rates 

EEA  2.3.4:  Effectiveness  of  various  firing  protocols 

EEA  2.3.5:  Effectiveness  of  munition/target  selections 

EEA  2.3.6:  Sufficiency  of  basic  loads  to  support  defined  missions. 

In  the  interest  of  space,  the  entire  list  of  MOEs  and  Data  Requirements  are  not  included  in 
this  report,  but  are  part  of  the  C*App  Final  Report  [4]. 

IV.  RESULTS 

Results  are  broken  out  based  on  the  two  U*App  objectives.  These  results  have  produced  a 
number  of  insights  and  lessons  learned,  many  of  which  are  more  fully  documented  in 
Reference  5. 

A.  VDLMS  M&S  Baseline 

VDLMS  baseline  metrics  were  identified  for  cost,  schedule,  and  performance. 

U'App  costs  include  those  funded  directly  by  the  VDLMS  STO,  funds  supporting  the 
underlying  NLOS  LS  Full  Scale  Simulation  (FSS),  and  funds  provided  by  individual  RDECOM 
organizations.  While  the  VDLMS  STO  allocated  $3.5M  to  execute  U*App,  this  amount  was 
more  than  matched  by  the  other  two  categories,  to  provide  a  total  of  approximately  $8.0M. 

The  l®*App  completion  date  was  fixed  due  to  availability  of  D&SA  BL  personnel,  and 
the  requirement  to  conclude  prior  to  the  FCS  Milestone  B  decision.  The  schedule  included  two 
weeks  of  record  runs  and  one  week  of  VIP  briefings,  as  is  shown  in  Figure  3.  Given  the  fixed 
schedule  endpoint,  length  of  time  to  gain  approval  for  classified  operation,  and  the  late  arrival  of 
funds,  the  distributed  site  integration  time  was  delayed  by  one  month  from  the  original  plan. 
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Figure  3.  F‘App  Schedule 

The  VDLMS  performance  results  from  F‘App  are  based  upon  the  size  of  the  scenario, 
the  complexity  of  the  federation,  the  number  of  successful  record  runs,  and  statistics  regarding 
network  and  HLA  performance. 

The  maximum  size  of  the  FCS  UA  slice  represented  within  stable  simulation  runtime 
was  for  Vignette  A,  consisting  of  one  entire  UA  less  two  maneuver  battalions,  plus  two  NLOS 
batteries  from  adjacent  UA’s,  and  two  High  Mobility  Artillery  Rocket  System  (HIMARS) 
batteries  and  two  Q47  radars  from  the  Unit  of  Employment  (UE).  Vignette  A  runs  executed  over 
the  course  of  approximately  3  hours,  and  peaked  at  roughly  2500  entities,  including  munitions  in 
flight.  Each  of  these  runs  produced  two  million  PDU’s,  logger  files  of  450MB,  and  1.3GB  HLA 
Results  database  files.  Vignette  B  was  a  1-hour  slice  of  Vignette  A,  scaled  down  to  about  500 
entities.  These  runs  each  produced  300,000  PDU’s,  55MB  logger  files,  and  500MB  HLA  Results 
databases. 


Eighteen  successful  record  runs  were  completed  over  the  2-week  run  period,  broken 
out  by  vignette  as  shown  in  Figure  3.  (In  addition.  Vignette  B  was  run  for  five  iterations  during 
VIP  demonstrations).  The  18  record  runs  were  out  of  a  total  of  21  attempts.  For  each  record  run, 
outstanding  simulation  problem  reports  were  documented  to  ensure  that  the  proper  analytical 
insights  could  be  drawn  from  each  run.  Since  final  integration  completion  overlapped  the  first 
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few  record  runs,  the  later  runs  tended  to  be  more  robust  than  the  earlier  ones  in  terms  of 
analytical  validity.  Along  with  the  freeplay  of  the  1^'App  roleplayers,  this  gave  each  run  a  unique 
personality  which  lent  its  utility  towards  addressing  the  various  networked  fires  metrics.  The 
total  stable  runtime  to  execute  these  18  record  runs  was  approximately  40  hours. 

Network  latencies  for  the  1^'App  WAN  ranged  from  2ms  to  36ms  based  on  ping  tests 
between  sites  across  the  DREN.  Throughput  losses  ranged  from  0  percent  with  1 8Mb 
connections  to  0.29  percent  with  4Mb  connections,  measured  from  each  site,  with  AMRDEC  as 
the  server.  Bandwidth  usage,  measured  at  AMRDEC,  was  as  shown  in  the  Table. 

Table.  Bandwidth  Utilization 


Vignette  A 

Average 

Maximum 

DIS 

0.37Mb/s 

9.67Mb/s 

HLA 

O.I3Mb/s 

2.67Mb/s 

Vignette  B 

Average 

Maximum 

DIS 

O.OOMb/s 

2.84Mb/s 

HLA 

0.02Mb/s 

I.43Mb/s 

Performance  for  the  simulation  layer  proved  to  be  very  stable  and  robust.  The  Mak 
RTI  and  Gateway  demonstrated  high  reliability  and  stability.  Joining  and  resigning  the 
federation  took  under  two  minutes  as  a  rule.  The  HE  A  Control  tool  allowed  the  federation  to 
monitor  object  updates  to  assist  in  federation  management. 

The  Mak  RTI  Exec  Graphical  User  Interface  (GUI)  did  cause  a  problem  with  joining 
and  rejoining,  requiring  federates  which  dropped  out  of  the  simulation  to  change  their  names 
before  rejoining.  This  bug  was  avoided  through  the  use  of  the  RTI  Exec  from  the  command  line 
interface.  The  RTI  Spy  was  also  disabled  for  similar  reasons. 

Other  issues  in  simulation  layer  performance  were  predominantly  in  the  areas  of 
federation  configuration,  gateway  configuration,  and  gateway  latencies.  Most  of  the  gateway 
latency  was  reduced  through  fine  tuning  the  configuration  file  settings,  but  significant  latencies 
were  experienced  between  simulations  on  separate  DIS  networks,  when  traffic  had  to  go  through 
two  gateways. 

Individual  performance  issues  were  identified  for  individual  federates.  Those  issues 
are  fully  documented  in  the  1^‘App  simulation  problem  report  database. 
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B.  Networked  Fires  Performance 


Networked  fires  performance  fell  into  two  categories;  the  general  performance 
mapping  to  the  EEAs  shown  above,  and  the  specific  performance  of  the  NLOS  LS  system  as  was 
addressed  in  the  underlying  ESS  experiment.  Detailed  NLOS  LS  metrics  and  results  can  be 
found  in  Reference  4.  General  NLOS  LS  observations  are  as  follows: 

•  A  key  observation  was  the  dominant  influence  of  ISR  and  targeting  processes  upon 
terminal  acquisition,  which  depends  upon  getting  the  footprint  of  the  missile  seeker  over  the 
target. 


•  The  representative  NLOS-LS  subnet  sustained  the  load  imposed  by  the  chiplet-based 
imagery  downlink  with  minimal  (<ls)  latencies. 

•  The  peak  load  on  the  NLOS-LS  subnet  was  approximately  2.8  Mb/s,  with  an  observed 
sustained  load  of  approximately  614  kb/s. 

•  The  load  imposed  on  the  NLOS-LS  network  was  driven  by  the  instantaneous  number 
and  type  of  reporting  missiles  in  flight  (approximately  70  Loitering  Attack  Missiles  (LAM)  and 
20  Precision  Attack  Missiles  (PAM))  and  waveform  compatible  relays.  (These  performance 
numbers  reflect  a  10:1  compression  ratio  for  the  downlinked  imagery,  and  sufficient  data  buffers 
on  each  relay). 

•  Full-LADAR-swath  imagery  downlink  from  LAM  can  be  supported  if  used 
judiciously. 

•  Frequent  Health  and  Status  messages  imposed  minimal  network  burden.  The  NLOS- 
LS  subnet  load  was  much  more  sensitive  to  target  density  than  node  count. 

•  The  prototype  Mission  Management  Applications  (surrogates  for  the  FCS  objective 
C2)  were  user-intensive,  effectively  limiting  the  number  of  active  NLOS-LS  missions. 

•  Common  control  measures,  grid  reference  and  symbology  between  all  command  and 
control  applications  are  required  for  synchronized  effects. 

•  The  LAM  exhibited  limited  Battle  Damage  Assessment  capability,  but  filled  a 
reconnaissance  and  surveillance  role  as  a  stop-gap  measure. 

•  Forward  sensors  (LFAV  and  armed  reconnaissance  helicopters)  were  key  contributors 
to  the  NLOS-LS  fight. 

For  the  general  networked  fires  performance,  the  EEAs  and  MoEs  were  translated  by 
AMSAA  into  a  set  of  eight  analysis  questions.  Comprehensive  analytical  answers  to  these 
questions  will  be  addressed  in  a  forthcoming  AMSAA  technical  report,  but  particular  insights  for 
each  question  are  offered  as  follows: 
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•  Question  1 :  Did  the  missile  network  impact  the  ability  to  command  and  control  both 
the  LAM  and  PAM?  -  The  “missile  network,”  in  this  context,  refers  to  the  radio  network,  nodes, 
relays,  and  control  stations  that  are  part  of  the  NLOS  LS  system,  as  opposed  to  the  more  general 
PCS  net-centric  system  to  execute  networked  fires.  While  this  question  is  addressed  in  more 
detail  by  the  FSS  effort,  in  general,  l^^App  demonstrated  that  the  missile  network  was 
sufficiently  robust,  including  the  necessary  radio  bandwidth,  for  the  command  and  control  of 
LAM  and  PAM  to  not  be  negatively  impacted,  even  with  imagery  being  passed  back  to  the 
control  stations.  l**App  demonstrated  adequate  functionality  and  bandwidth  to  support 
redirection  and  changes  in  missions  and  waypoints  for  LAMs  in  flight,  as  well  as  target  updates 
for  PAM. 


•  Question  2:  How  hard  is  it  for  an  operator  to  control  the  LAM  ?  This  question  is 
specifically  addressed  by  the  functionality  of  two  federates:  FIRESIM  and  the  NLQS  LS  MMA. 
Both  use  plan  view  displays  to  insert  waypoints,  select  loiter  regions,  and  retask  missiles  in 
flight.  Both  of  these  applications  have  their  strengths  and  weaknesses,  but  both  provided 
sufficient  control  for  LAM  as  surrogates  for  a  definitive  operator  interface,  and  as  prototypes  for 
the  tactical  solution.  Difficulty  of  operator  control  would  be  considered  low,  based  on  the  fact 
that  1^'App  was  able  to  execute  all  LAM  missions  requested,  and  produced  repeated  peaks  of  up 
to  seventy-five  LAMs  in  flight. 

•  Question  3:  How  is  the  information  displayed  on  the  various  Common  Qperational 
Picture  (CQPi  displays  used?  Answering  this  question  is  complicated  by  the  fact  that  1^‘App 
utilized  several  simulations  with  overlapping  functionality  rather  than  representing  a  true  CQP. 
However,  collectively,  the  CQP  information  was  successfully  used  for  situational  awareness, 
weapon-target  pairing,  fire  mission  planning,  and  all  other  functions  required  to  execute 
networked  fires. 

•  Question  4:  What  are  the  time  lines  and  latencies  between  major  segments  of  the 
engagement  process?  Detailed  timelines  were  produced  from  C‘App,  but  in  the  interest  of  space, 
are  not  addressed  here. 

•  Question  5:  What  is  the  impact  of  the  sensor  coverage  on  mission  effectiveness? 
Sensor  coverage  seemed  sufficient  for  mission  effectiveness,  but  there  were  limitations  on  the 
ability  of  Class  11  UAVs  to  adequately  acquire  targets  based  on  flight  profiles  coupled  with 
sensor  performance,  and  a  simulation  limitation  in  retasking  the  IDEEAS  UAVs  which  limited 
the  ability  to  dynamically  adapt  sensor  coverage  for  all  missions. 

•  Question  6:  How  effective  were  the  CQP  display  systems  in  portraying  BDA?  During 
the  record  runs,  several  different  methodologies  were  explored  to  highlight  targets  with  known 
damage,  and  targets  that  had  been  engaged.  A  very  interesting  process  was  established  to  cross- 
reference  MTl  reports  with  Counter-Mortar  Counter-Battery  (CMCB)  radar  to  determine  shoot- 
and-scoot  behaviors  to  infer  BDA.  Qther  BDA  sensing  was  limited  due  to  the  resolution  of  target 
model  visual  representations. 

•  Question  7:  How  well  did  the  networked  fires  reduce  the  threat  force?  In  both  C^App 
vignettes,  the  blue  force  decimated  the  red  force.  Actual  attrition  data  is  not  available  in 
unclassified  form. 
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•  Question  8:  What  was  the  munitions  expenditure  rate?  Munitions  expenditures  were 
explicitly  accounted,  but  in  the  interest  of  space,  are  not  discussed  here. 

V.  CONCLUSIONS 

With  the  successful  execution  of  18  record  runs  of  a  significant  slice  of  an  PCS  UA,  l^*App 
met  its  success  criteria  and  demonstrated  that  current  RDECOM  simulation  resources  and  tools 
are  relevant  to  PCS  and  the  OP,  and  sufficient  to  answer  a  number  of  analytical  questions.  It  also 
demonstrated  a  performance  baseline  to  ground  the  emerging  MATREX  architecture  as  the 
community  evolves  to  be  able  to  address  engineering  and  technical  issues  in  UA  and  UE 
contexts. 
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